Configure Helm TLS communication with multiple Kubernetes clusters

Maor Friedman

Follow

Nuvo Tech

--

So, finally decided to secure your Helm installation? That`s great! Sounds easy enough, right? And as an extra, all sources seem to be telling the exact same story: “All you have to do is follow these steps, and you are good to go”. Right? Wrong. Well, not really wrong, it is a fairly simple procedure, but brace yourself for more typing. Much more. A bit more. There you are. But have no fear, the solution is here (in this post, if that was unclear).

Let`s start with a basic description of Helm. Helm helps you manage Kubernetes applications (Helm charts). Think of it this way: Helm to Kubernetes is much like APT is to Debian. It helps you define, install or upgrade applications. Helm is comprised of a client side (helm, runs on your laptop, your CI/CD pipelines, etc) and a server side (tiller, runs inside your cluster).

Helm is easy to install on your cluster, and if you care about security, you will probably want to follow the Best practices for securing Helm and Tiller. The official documentation is very good and will take you step by step from zero to Helm security hero in no time. We are going to skip the installation part, and focus on what happens after you are running securely.

A note about securing an existing Helm installation — The only potentially breaking part is to migrate existing Releases from ConfigMap to Secret objects. This can be handled using this tool by Kirill Kuznetsov. Good job on that one!

Once you have TLS in place, the first question you are going to be asking is how can you avoid typing so much. To use any Helm commands that communicate with Tiller, you will need to type something like:

This is obviously too much for a simple ls command, and if you copy the necessary files to the Helm home directory, you can simply type:

So far, so good. If you administer only one cluster, you are probably satisfied at this point. Adding --tls to (some) commands does not seem to be too much of a hassle. You will be seeing a lot of Error: transport is closing due to --tls-forgetfulness at first (doh!), but eventually it will grow on you.

But what if you administer multiple clusters and have different certificates and keys for each of them? The shortcut of having the files in your Helm home directory does not work anymore, and you are left at the mercy of --home /path/to/k8s.cluster.n/certs. If adding --tls was bearable, --home is just too much.

We need to find a solution that will allow us to type less and say more — an alias!

Consider the following folder structure:

Place the appropriate cert.pem and key.pem in each of these folders. Just to be clear, k8s.cluster.n is meant to be the names of each of the clusters you administer. After having this structure, you can add the following line to your aliases:

This alias gets the current cluster from your Kubernetes config file, and prints all arguments needed to call Tiller. So, to use this alias, you will type:

Quite a time saver already. we are down to the acceptable helm ls --tls, only written a bit differently, and works for multiple clusters.

Another nice shortcut would be to add this line to your aliases:

Introducing Helmet! Hagai Barel had the idea of the name Helmet — Helm Enable TLS (be sure to check out his posts). So now you can just type:

This is definitely something I`m willing to live with. I do still suffer the occasional tls-forgetfulness, but this can be easily treated with some Bash Shortcuts, specifically this sequnce: Arrow-up, Ctrl+A, Ctrl+Arrow-right, et, Enter.

To summarize, this is without a doubt a great time saver, but helmet has its drawbacks. For one, it does not handle multiple Tillers in a single cluster. This is maybe a place where we will need something a bit more powerful than an alias and a folder structure.

With Helm 3 coming up, secure communication between Helm and Tiller will no longer be required, because… there will be no more Tiller! Read more here.

Thanks for reading!